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Foreword 



rd , 



This Technical Specification (TS) has been produced by the 3' Generation Partnership Project (3GPP). 

The present document is part 2 of a muhi-part TS covering the 3"* Generation Partnership Project: Technical 
Specification Group Services and System Aspects; Telecommunication Management; Configuration Management, as 
identified below: 

Part 1: "3G Configuration Management: Concept and Requirements"; 

Part 2: "Notification Integration Reference Point: Information Service Version 1"; 

Part 3: "Notification Integration Reference Point: CORBA Solution Set Version 1:1"; 

Part 4: "Notification Integration Reference Point: CMIP Solution Set Version 1:1"; 

Part 5: "Basic Configuration Management IRP Information Model (including NRM) Version 1"; 

Part 6: "Basic Configuration Management IRP CORBA Solution Set Version 1:1"; 

Part 7: "Basic Configuration Management IRP CMIP Solution Set Version 1:1"; 

Part 8: "Name Convention for Managed Objects". 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 



Configuration Management (CM), in general, provides the operator with the ability to assure correct and effective 
operation of the 3G network as it evolves. CM actions have the objective to control and monitor the actual configuration 
on the Network Elements (NEs) and Network Resources (NRs), and they may be initiated by the operator or by 
functions in the Operations Systems (OSs) or NEs. 

CM actions may be requested as part of an implementation programme (e.g. additions and deletions), as part of an 
optimisation programme (e.g. modifications), and to maintain the overall Quality Of Service (QOS). The CM actions 
are initiated either as a single action on a NE of the 3G network or as part of a complex procedure involving actions on 
many NEs. 

The Itf-N interface for Configuration Management (CM) is built up by a number of Integration Reference Points (IRPs) 
and a related Name Convention, which realise the functional capabilities over this interface. The basic structure of the 
IRPs is defined in 3GPP TS 32.101 [7] and 3GPP TS 32.102 [8]. For CM, a number of IRPs (and the Name 
Convention) are defined herein, used by this as well as other specifications for Telecom Management produced by 
3GPP. All these are included in 3GPP TS 32.106 from Part 2 and onwards. 

The present document is Part 2 of 3GPP TS 32.106 (3GPP TS 32.106-2) - Notification IRP Information Service. 
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1 Scope 



Network Elements (NEs) under management generate events to inform event receivers about occurrences within the 
network that may be of interest to event receivers. There are a number of categories of events. Alarm, as specified in 
Alarm IRP: Information Service 3GPP TS 32.111-2 [1], is one member of this category. 

The purpose of Notification IRP is to define an interface through which an IRPManager (typically a network 
management system) can subscribe to IRP Agent (typically an Element Manager (EM) or a NE) for receiving network 
events. It also specifies attributes carried in the network events. These attributes are common among all event 
categories. Attributes that are specific to a particular event category are not part of the present document. For example, 
perceivedSeverity is an attribute specific for alarm event category. This attribute is not defined the present 
document but in Alarm IRP 3GPP TS 32. 1 1 1-2 [1]. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] 3GPP TS 32.1 1 1-2: "Alarm IRP: Information Service". 

[2] Void 

[3] ITU-T Recommendation X.734 (09/92): "Information technology - Open Systems Interconnection 

- Systems management: Event report management function". 

[4] 3GPP TS 32. 106-8: "Name Convention for Managed Objects". 

[5] Void 

[6] OMG: "OMG Notification Service". 

[7] 3GPP TS 32.101: "3G Telecom Management principles and high level requirements". 

[8] 3GPP TS 32.102: "3G Telecom Management architecture". 

[9] 3GPP TS 32.106-1: "3G Configuration Management: Concept and Requirements". 

[10] ITU-T Recommendation X.730: "Object Management Function". 

[II] ITU-T Recommendation X.731: "State Management Function". 
[12] Void 

[13] ITU-T Recommendation X.733: "Alarm Reporting Function". 

[14] ITU-T Recommendation X.736: "Security Alarm Reporting Function". 
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Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply. For terms and definitions not 
found here, please refer to 3GPP TS 32.101 [7], 3GPP TS 32.102 [8] and 3GPP TS 32.106-1 [9]. 

IRPAgent: See 3GPP TS 32.102 [8]. 

IRPManager: See 3GPP TS 32.102 [8]. 

Event: It is an occurrence that is of significance to network operators, the NEs under surveillance and network 
management applications. Events can indicate many types of network management information, such as network 
alarms, network configuration change information and network performance data. 

Extended Event Type: ITU-T TMN defines event types. Examples are: Object Creation, Object Deletion, Attribute 
Value Change, State Change, Communications Alarm, Processing Error Alarm, Environmental Alarm, Quality of 
Service Alarm, Equipment Alarm, Integrity Violation, Security Violation, Time Domain Violation, Operational 
Violation, Physical Violation. Valid values of this set are controlled by ITU-T. 

The 3GPP Working Group SA5's (Telecommunication Management) work on IRP requires definitions beyond those 
ITU-T defined event types. Examples are: 

• Indicate alarm acknowledgement state changes; 

• Indicate Alarm List (defined in Alarm IRP: IS 3GPP TS 32.111-2 [1]) has rebuih successfully. 

This set is called extendedEventType. Valid values for this set are specified by this IRP. 

Notification: It refers to the transport of events from event producer to consumer (receiver). In this IRP, notification is 
used to carry network events from IRPAgent to IRPManager. Producer sends notifications to consumers as soon as 
there are new events occur. Consumer does not need to check ("pull") for events. 

It may be reused if there is no requirement that the previous notification using that Notification identifier be correlated 
with future notifications. Generally, IRPAgent should choose it to ensure uniqueness over as long a time as is feasible 
for the IRPAgent. 

Notification Category: One Notification Category defines the set of all event types and all extended event types 
specified by one IRP. Neither an event type nor an extended event type may belong to more than one Notification 
Category. 

Qualifiers: Qualifiers for operations, notifications and attributes (whether they are Mandatory(M)/ Conditional(C)/ 
Optional(O)) are defined in the present (Information Service) document, but not for corresponding parameters in the 
solution set documents (as they are meaningless there). Mandatory and Conditional qualifiers shall always be the same 
in other IRPs using items from the Notification IRP IS (the present document), but Optional qualifiers may in the other 
IRPs be set to either Optional or Mandatory. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

C Conditional 

CM Configuration Management 

CORBA Common Object Request Broker Architecture 

DN Distinguished Name 

EM Element Manager 

FM Fault Management 

IDL Interface Definition Language 

IRP Integration Reference Point 

IS Information Service 
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ITU-T 

M 

MIB 

MIM 

MOC 

MOI 

NE 

NM 

NR 

NRM 

O 

OMG 

SS 

TMN 

UML 



International Telecommunication Union, Telecommunication Standardisation Sector 

Mandatory 

Management Information Base 

Management Information Model 

Managed Object Class 

Managed Object Instance 

Network Element 

Network Manager 

Network Resource 

Network Resource Model 

Optional 

Object Management Group 

Solution Set 

Telecommunications Management Network 

Unified Modelling Language (OMG) 



4 System overview 

4.1 System context for Notification 

Figure 1 and Figure 2 identify System contexts of Notification IRP in terms of implementations called IRP Agent and 
IRPManager. 

"IRPManager" depicts a process that interacts with IRP Agent for the purpose of receiving network Notifications via 
this IRP. IRP Agent detects network events. IRP Agent sends IRPManagers notifications carrying the events. Examples 
of IRPManagers can be a process running supporting network Notification logging device or supporting network 
Notification viewing devices (such as a local craft terminal) or a process running within a Network Manager (NM) as 
shown in Figure 1 and Figure 2. IRP Agent implements and supports this IRP. IRP Agent can run within one Element 
Manager (EM) with one or more NEs (see Figure 1) or run within one NE (see Figure 2). In the former case, the 
interfaces (represented by a thick dotted line) between the EM and the NEs are not subject of this IRP. Whether EM 
and NE share the same hardware system is not relevant to this IRP either. By observing the interaction across the IRP, 
one cannot deduce if EM and NE are integrated in a single system or if they run in separate systems. 
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Figure 1 : System Context A 
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Figure 2: System Context B 

This interface supports the following implementation strategies. 

• One IRP Agent supports emission of different categories of Notifications, such as alarms (as specified in 
3GPPTS 32.111-2 [1]) and others. 

• One IRP Agent supports emission of one specific category of Notification. For example, one IRP Agent 
implementation only emits alarms specified in 3GPP TS 32.1 1 1-2 [1]. Another IRP Agent implementation emits 
configuration status change notifications. 

• IRPManager can specify the categories of notifications it wants to receive using subscribe operation. In the 
case IRPManager does not specify the notification category in subscribe, IRP Agent will then emit all categories 
of notifications that IRP Agent handles. This implementation is SS dependent. 

• IRPManager can query the categories of notification supported by IRP Agent. This implementation is Solution Set 
(SS) dependent. 

The Notification IRP defines attributes, carried in notifications that are common in all categories of notifications. 

Attributes specific to a particular category of notification shall be specified in corresponding IRP (such as Alarm IRP IS 
- see 3GPP TS 32.1 1 1-2 [1]) using the Notification IRP. Those IRP also define the protocol interaction via which 
IRPManager receives the notifications. 

5 Modelling approach 

This clause identifies the modelling approach adopted and used in this IRP. 

This IRP bases its design on work captured in ITU-T Recommendation X.734 [3], OMG Notification Service [6]. The 
central design ideas are: 

• Separation of notification Consumers (IRPManagers) from Producers (IRPAgents); 

• Notifications are sent to IRPManagers without the need for IRPManagers to periodically check for new 
notifications. 

• Common characteristics related to notifications in all other IRPs are gathered in one IRP (the present document). 

6 IRP Information Service 
6.1 Interfaces 

Figure 3 illustrates the operations and notifications defined as interfaces implemented and used by IRP Agent and 
IRPManager. Parameters and return status are not indicated. Interface in IRP Information Service is identical to 
concept conveyed by stereotype «inter f ace» of UML. 

One interface, called Notif icationlRPOperations, is defined. This interface defines operations implemented 
by IRP Agent and used (or called by) IRPManager. 
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Figure 3: Protocol independent interface 



6.1.1 Notification! RPOperation Interface 



6.1.1.1 



Operation subscribe (M) 



IRPManager invokes this operation to establish subscription to receive network events via notifications, under the fiher 
constraint specified in this operation. How IRPManager discovers the IRPAgent' s address or reference (so that 
IRPManager can invoke this operation) is outside the scope of the present document. 

Tabie 1 : Parameters of subscribe 



Name 


Qualifier 


Purpose 


managerRef erenc 
e 


Input, M 


It specifies the reference of IRPManager to which IRPAgent shall send events. 


timeTick 


Input, O 


It specifies the value of a timer hold by IRPAgent for the subject IRPManager. 
This value defines a time window within which IRPManager intends to invoke 
getSubscriptionStatus (or subscribe) operation. IRPAgent shall 
reset the timer, with timeTick, when it receives the 

getSubscriptionStatus (or subscribe) operation from the subject 
IRPManager. If the timer expires, IRPAgent may delete its resources allocated 
to the IRPManager and consider IRPManager as if it has invoked 
unsubscribe operation. In such case, IRPManager will not receive further 
notification. IRPManager needs to invoke subscribe operation again. 
The value is in unit of whole minute. 

If the value is between 1 and 15, IRPAgent considers it to be 15. 
If the parameter is absent or if the parameter is present but its value is negative 
or 0, IRPAgent shall treat timeTick value as infinite, i.e., timer will never 
expire and IRPAgent needs other means to decide when to delete resources 
allocated to the IRPManager. 


notification 
Categories 


Input, O 


It identifies one or more Notification Categories (see also definition in 
subclause 3.1). 

If the parameter is absent, IRPAgent shall consider IRPManager is subscribing 
to all notification categories supported by IRPAgent. 
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filter 


Input, O 


It specifies a filter constraint that IRP Agent shall use to filter notification of the 
category specified in notif icationCategory parameter. IRP Agent shall 
notify IRPManagers if the event satisfies the filter constraint. 
If this parameter is absent, then no filter constraint shall be applied. Valid filter 
constraint grammars are specified by individual notification IRP SS, e.g. 
Notification IRP: CORE A SS. 


sub script ion Id 


Output, M 


It holds an unambiguous identity of this subscription. IRPManager can invoke 
operations (e.g., suspendSubscription) using this identity. In normal 
usage, IRPManager shall not provide this identity to another IRPManager such 
that the second IRPManager can invoke operations using it. 


status 


Output, M 


(a) Operation succeeded in that the requested subscription has been established 
successfully AND that IRP Agent is emitting categories of notification specified 
by IRPManager via the notif icationCategory parameter AND that the 
filter, if present, contains a vaHd filter constraint. 

(b) Operation failed because IRPManager is already in subscription, i.e., 
IRP Agent detects that there is an existing subscription carrying the same 
managerRef erence and in subscription for the same 

not if icationCategory. 

(c) Operation failed because of other specified or unspecified reason. 



6.1.1.2 



Operation unsubscribe (M) 



The IRPManager invokes this operation to cancel subscriptions. The IRPManager can cancel one subscription by 
providing the corresponding subscriptionid or all subscriptions by leaving the subscriptionid parameter absent. 

Table 2: Parameters for unsubscribe 



Name 


Qualifier 


Purpose 


manager 
Reference 


Input, M 


It specifies the reference of IRPManager. IRPManager shall supply its valid 
managerRef erence. This is the necessary requirement for the operation to 
be successful. 


subscriptionid 


Input, O 


It carries the subscriptionid carried as the OUT parameter in the 
subscribe operation. IRPManager shall supply a specific 
subscriptionid if IRPManager wants to unsubscribe that particular 
subscription. IRPManager shall not supply subscriptionid (the 
parameter is absent) if it wants to unsubscribe all subscriptions established 
between IRP Agent and this managerRef erence. 


status 


Output, M 


(a) Operation succeeded in that subscription is cancelled successfully. 

(b) Operation failed because of specified or unspecified reason. 



6.1.1.3 



Operation getNotif icationlRPVersion (M) 



IRPManager wishes to find out the Notification IRP SS versions supported by IRP Agent. IRP Agent shall respond with 
a list of Notification IRP SS version(s). 

Table 3: Parameters for getNotif icationiRPVersion 



Name 


Qualifier 


Purpose 


versionNumberList 


Output, M 


It indicates one or more SS version numbers supported by the IRP Agent. In 
Release 99, it shall contain only one version number. 


status 


Output, M 


(a) Operation succeeded in that versionNumberList contains vaHd 
result. 

(b) Operation failed. Output parameter versionNumberList may 
contain invalid result. 



£75/ 



3GPP TS 32.106-2 version 3.3.0 Release 1999 



11 



ETSI TS 132 106-2 V3.3.0 (2001-03) 



6.1.1.4 Operation getSubscriptionStatus (O) 

IRPManager invokes this operation to query the subscription status of a particular subscription. 

IRPManager can get similar service by invoking subscribe operation. However, the following differences are 
noted. 

• Operation subscribe uses managerReference and this operation uses subscriptionld. 

• If IRP Agent has lost IRPManager' s reference, IRPManager use of subscribe operation may result in 
establishment of another subscription. Using this operation does not establish another subscription. 

• IRPManager can use getSubscriptionStatus operation to know about the filter constraint in effect, the state 
of subscription (i.e., if subscription is suspended/inactive or resumed/active), the timeTick value that may 
be set at subscribe invocation time and the notificationCategory currently in used in the subscription. 

Table 4: Parameters for getSubscriptionStatus 



Name 


Qualifier 


Purpose 


subscriptionld 


Input, M 


It carries the subscriptionld carried as the output parameter in the 
subscribe operation. 


notification 
CategoryList 


Output, M 


It identifies the notificationCategory or notificationCategories supported in this 
subscription. 


filterlnEffect 


Output, 


It contains the filter constraint currently active. If it is absent, IRPManager 
shall not apply any filter constraint to notifications emitted towards the subject 
IRPManager. 


subscription 
State 


Output, 


It indicates if the subscription is in "suspended" or "not-suspended". 


timeTick 


Output, O 


It carries the same value as the one in subscribe operation. 


status 


Output, M 


(a) Operation is successful and IRP Agent has valid values for all output 
parameters. 

(b) Operation is unsuccessful in that IRP Agent has no knowledge of the 
subscription. 



6.1.1.5 



Operation getSubscriptionlds (O) 



IRPManager invokes this operation to get the values of all still valid subscriptionlds assigned by IRP Agent as 
result of previously subscribe operations performed by this IRPManager. 

Table 5: Parameters for getSubscriptionlds 



Name 


Qualifier 


Purpose 


managerRef erenc 
e 


Input, M 


It specifies the reference of IRPManager that requests the list of identifiers of 
active subscriptions related to this IRPManager. 


subscriptionldL 
ist 


Output, M 


It carries a list of the subscriptionld, each assigned as OUT parameter 
in previous subscribe operations invoked by the current IRPManager. 
This value should contain no information if the IRPManager did not yet 
subscribed to that System or System lost all subscription related information. 


status 


Output, M 


(a) Operation succeeded in that the value contained in OUT parameter is 
vaHd. 

(b) Operation failed because subscription information is lost or IRP Agent 
cannot complete the operation for other reasons. In this case, the OUT 
parameter shall contain no information. 
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6.1.1.6 Operation changeSubscriptionFilter (O) 

IRPManager invokes this operation to replace the present filter constraint with a new one. 

Table 6: Parameters for changeSubscriptionFilter 



Name 


Qualifier 


Purpose 


subscriptionid 


Input, M 


It carries the subscriptionid carried as the OUT parameter in the 
subscribe operation. 


filter 


Input, M 


See description of Table 1: Parameters of subscribe. 


status 


Output, M 


(a) Operation succeeded in that IRP Agent is now producing events based on 
the new filter constraint. 

(b) Operation failed in that, for unspecified reason, the new filter constraint 
cannot be installed. The old filter constraint, if present before this 
operation, is still in effect. 



6.1.1.7 



Operation suspendSubscription (O) 



IRPManager invokes this operation to request IRP Agent to stop emission of notifications. IRP Agent may lose 
notification(s) if subscription is suspended. 

Table 7: Parameters for suspendSubscription 



Name 


Qualifier 


Purpose 


subscriptionid 


Input, M 


It carries the subscriptionid carried as the OUT parameter in the 
subscribe operation. 


status 


Output, M 


(a) Operation succeeded in that IRP Agent has suspended emission of 
notifications. 

(b) Operation failed in that, for unspecified reason, IRP Agent has not 
suspended emission of events. 



6.1.1.8 Operation resumeSubscription (O) 

IRPManager invokes this operation to request IRP Agent to resume emission of notifications. If the Subscription 
State is "not-suspended", IRP Agent shall return status successful and ignore this invocation. If 
Subscription State is "suspended", IRP Agent shall return status successful, change the Subscription 
State to "not-suspended" and resume emission of notifications. 

Table 8: Parameters for resumeSubscription 



Name 


Qualifier 


Purpose 


subscriptionid 


Input, M 


It carries the subscriptionid carried as the OUT parameter in the 
subscribe operation. 


status 


Output, M 


(a) Operation succeeded in that IRP Agent is has resumed emission of events. 

(b) Operation failed in that, for unspecified reason, IRP Agent cannot resume 
emission of events. 



6.1.1.9 



Operation getNotif icationCategories (O) 



IRPManager invokes this operation to query the categories of notification supported by IRP Agent. IRPManager does 
not need to be in subscription to invoke this operation. 
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Table 9: Parameters for getNotif icationCategories 



Name 


Qualifier 


Purpose 


notification 
CategoryList 


Output, M 


It identifies the list of notification categories supported by IRP Agent (see also 
definition in subclause 3.1). 

If this parameter value contain no information, then the meaning is that IRP Agent 
does not support any notification category at the moment. 


eventTypeList 


Output, 


It contains a list of elements. Each element is a list of eventType. The number of 

element shall be identical to that of output parameter notificationCategoryList. 

The n-th element of this list relates to the n-th element of the 

notificationCategoryList. 

IRP Agent shall not use arbitrarily any eventType(s) in this n-th element. IRP Agent 

shall use the same list of eventType(s) specified in the IRP document identified by 

the n-th element of the notificationCategoryList. 

If the n-th element contains no information, it implies IRP Agent is not providing 

explicit identification of eventType(s) of the corresponding notificationCategory. 

If this parameter is absent or contains no information, it implies that IRP Agent is not 

providing explicit identification of eventType(s). 


extendedEvent 
TypeList 


Output, O 


It contains a Ust of element. Each element is a list of extendedEventType. The 

number of element shall be identical to that of output parameter 

notificationCategoryList. 

The n-th element of this list relates to the n-th element of the 

notificationCategoryList. 

IRP Agent shall not use arbitrarily any extendedEventType in this n-th element. 

IRP Agent shall use the same list of extendedEventType specified in the IRP 

document identified by the n-th element of the notificationCategoryList. 

If the n-th element contains no information, it implies IRP Agent is not providing 

explicit identification of extendedEventType(s) of the corresponding 

notificationCategory. 

If this parameter is absent or contains no information, it implies that IRP Agent is not 

providing explicit identification of extendedEventType(s). 


status 


Output, M 


(a) Operation succeeded in that the output parameter contains valid information. 

(b) Operation failed in that the output parameter does not contain valid information. 



6.1.2 NotificationlRPNotification Interface 



6.1.2.1 



Notification notify 



IRP Agent notifies the subscribed IRPManager that an event has occurred and that the event has satisfies the filter 
constraints used for this subscription. One event example is the notification defined in Alarm IRP: IS 

(3GPPTS 32.111-2 [1]). 

The present document does not further specify this notify. Other IRPs using the Notification IRP, such as Alarm 
IRP: IS (3GPP TS 32.111-2 [1]), shall specify this notify, in particular, the specific parameters carried in notification, 
for use in their context. 

The present document shall specify, in subclause 6.1.2.2, attributes commonly carried in parameters of all notifications. 

6.1 .2.2 Notification Attributes 

Information about network events is carried in notification containing parameters of multiple attributes. This IRP 
specifies attributes that are commonly found in notifications defined by other IRPs. Collectively, they are called 
Notification Header. Other IRPs using the Notification IRP, such as Alarm IRP: IS (3GPP TS 32. 1 1 1-2 [1]), shall 
specify the attributes used in the notification including: 

• Identification and qualification of notification Header attributes for their use; 

• Specification and qualification of other attributes relevant for their use. 
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6.1.2.2.1 managedOb jectClass (M) 

This parameter specifies the class of the Managed Object (MO) in which the network event occurred. This attribute is 
filterable. 

6.1.2.2.2 managedOb jectlnstance (M) 

This parameter specifies the instance of the MO in which the network event occurred. This attribute is filterable. 

6.1.2.2.3 notificationld(O) 

This parameter provides an identifier for the notification, which may be carried in the 

correlatedNotif ications parameter (see below) of future notifications. Attribute notif icationid shall 
be chosen to be unique across all notifications of a particular managed object throughout the time that correlation is 
significant. 

It uniquely identifies this notification from other notifications generated by the subject MO. 

If IRPManager receives notifications from one IRP Agent, IRPManager shall use notif icationid and 
managedOb jectlnstance to uniquely identify all received notifications. 

If IRPManager receives notifications from multiple IRP Agents and notifications of each MO are reported at most 
through one IRP Agent, IRPManager shall use notificationid and managedOb jectlnstance to uniquely 
identify all received notifications. 

If IRPManager receives notifications from multiple IRP Agents and notifications of one or more MOs are reported 
through two or more IRP Agents, IRPManager shall use notificationid, together with 

managedOb jectlnstance and the identity of IRP Agent, to uniquely identify all received notifications. Attribute 
systemDN, if present, carries IRP Agent's identify. If systemDN is absent, IRPManager needs other means, which 
are outside the scope of this IRP, to determine the identity of IRP Agent. 

If and when the value of this can be re-used is specified in SSs. 

This attribute is filterable. 

6.1.2.2.4 eventTime (M) 

It indicates the event occurrence time. The semantics of Generalised Time specified by ITU-T shall be used here. 
This attribute is filterable. 

6.1.2.2.5 systemDN (C) 

It carries the Distinguished Name (DN) of IRP Agent that detects the network event and generates the notification. See 
3GPP TS 32.106-8 [4] for name convention regarding DN. 

This attribute is filterable. 

6.1.2.2.6 eventType (M) 

It carries identification of the type of event reported by the notification. Allowed event types are ITU-T TMN defined 
event types. Examples of ITU-T TMN event types are: 

• Object Creation (ITU-T Recommendation X.730 [10]) 

• Object Deletion (ITU-T Recommendation X.730 [10]) 

• Attribute Value Change (ITU-T Recommendation X.73 1 [11]) 

• State Change (ITU-T Recommendation X.73 1 [ 1 1]) 



£75/ 



3GPP TS 32.1 06-2 version 3.3.0 Release 1 999 15 ETSI TS 1 32 1 06-2 V3.3.0 (2001 -03) 

Communications Alarm (ITU-T Recommendation X.733 [13]) 

Processing Error Alarm (ITU-T Recommendation X.733 [13]) 

Environmental Alarm (ITU-T Recommendation X.733 [13]) 

Quality of Service Alarm (ITU-T Recommendation X.733 [13]) 

Equipment Alarm (ITU-T Recommendation X.733 [13]) 

Integrity Violation (ITU-T Recommendation X.736 [14]) 

Security Violation (ITU-T Recommendation X.736 [14]) 

Time Domain Violation (ITU-T Recommendation X.736 [14]) 

Operational Violation (ITU-T Recommendation X.736 [14]) 

Physical Violation (ITU-T Recommendation X.736 [14]) 

Each IRP document using the Notification IRP, such as Alarm IRP: IS (3GPP TS 32.1 11-2 [1]), identifies which 
eventType shall be used for that IRP. 

This attribute is filterable. 

6.1.2.2.7 extendedEventType (M) 

IRP Agent, in certain situations, may generate notifications of types whose semantics are extended beyond those defined 
by ITU-T event types. Examples are: 

• Indicate alarm acknowledgement state changes 

• Indicate Alarm List of AlarmlRP Agent has rebuilt successfully. 

This attribute carries the required extension. 

Each IRP document using the Notification IRP, such as Alarm IRP: IS (3GPP TS 32.1 1 1-2 [1]), defines the extended 
event types required. 

This attribute is filterable. 

6.1.3 Behaviour 

6.1 .3.1 IRPAgent supports multiple subscriptions with one IRPManager 

An IRPManager can have multiple managerRef erences. IRPManager can invoke subscribe operations using 
different managerRef erences resulting in multiple subscriptions. As far as IRPAgent is concerned, the IRPAgent 
is sending alarms to multiple "places". 

If IRPManager invokes multiple subscriptions with identical managerRef erence and 

notif icationCategory combination, all but one subscription shall fail with exception indicating that the 

IRPManager is already in subscription. 

If IRPManager has established subscription by invoking subscribe with notif icationCategory parameter 
absent, subsequent subscribe, either with notif icationCatgory absent or present, using the same 
managerRef erence, shall fail. IRPAgent shall throw exception indicating that the IRPManager is already in 
subscription. 

IRPManager controls the filter constraint via subscribe and changeSubscriptionFilter operations. 
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6.1 .3.2 Support of packing multiple notifications 

It should be possible to pack multiple notifications together for sending to NM. This provides more efficient use of data 
communication resources. In order to pack multiple notifications, an EM/NE configurable parameter defines the 
maximum number of notifications to be packed together. Additionally an EM/NE configurable parameter defines the 
maximum time delay before the notifications have to be sent. 

6.1 .3.3 IRPAgent supports emission of multiple Notification categories 

IRP Agent supporting this IRP may emit multiple categories of notifications. For example, it may emit notification 
defined in Alarm IRP 3GPP TS 32. Ill -2 [1]. IRPAgent supports mechanism that IRPManager can use to determine the 
categories of notifications supported by IRPAgent. IRPAgent also supports mechanism that IRPManager can use to 
specify the categories of notifications IRPAgent should emit to IRPManager during subscription. 

6.1 .3.4 Subscription list loss 

IRPAgent can lose the list of managerRef erence that identifies current IRPManagers under subscription. Under 
this condition, IRPAgent is incapable of sending events to the affected subscriber(s). 

This Notification IRP recommends that IRPManager should invoke the getSubscriptionStatus operation 
periodically to confirm that IRPAgent still has the IRPManager' s reference in its list. In case IRPManager does not 
obtain a positive confirmation, IRPManager should assume that IRPAgent has lost the IRPManager's reference. In this 
case, IRPManager should invoke unsubscribe and then subscribe operation again. 

This IRP does not recommend the frequency IRPManager should use to invoke getSubscriptionStatus 
operation. 

6.1.3.5 Notification ordering 

Under normal operations, an IRPAgent shall send, to each IRPManager, notifications in the same order they were 
generated, i.e. in the First-In, First-Out order. Notifications of one Event Type and/or Extended Event Type shall not be 
given priority over other Event Types and/or Extended Event Types. 
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